build(deps): bump postcss from 8.5.19 to 8.5.26 - #170

* deps: resolve 123 Dependabot security alerts (safe, non-breaking) (#136)

* deps: resolve non-breaking Dependabot alerts (category 1)

Apply safe, in-major security fixes across all three lockfiles via npm
overrides pinned to GHSA-patched versions plus range-respecting updates
(no major-version bumps). Resolves 125 of 160 open Dependabot alerts.

Root package.json overrides: @xmldom/xmldom, cipher-base, fast-uri,
flatted, follow-redirects, form-data, koa, launch-editor, lodash, morgan,
node-forge, on-headers, pbkdf2, postcss, protobufjs, qs,
serialize-javascript, sha.js, shell-quote, tmp, undici, ws. Also bump
webpack devDependency to ^5.104.1 and range-update ajv, bn.js, glob,
tar-fs, picomatch, minimatch, brace-expansion, nanoid, playwright.

src.gen streaming clients: npm audit fix (lodash, minimatch,
@smithy/config-resolver) and override fast-xml-parser to 4.5.7.

Remaining alerts require major-version bumps or coordinated @aws-sdk
upgrades and are handled separately.

* deps: revert webpack bump to keep web build passing

Problem:
The webpack ^5.95.0 -> ^5.104.1 bump (added to fix SSRF alerts #68/#69)
pulls webpack 5.108.4 and enhanced-resolve 5.24.2. The newer resolver
applies stricter exports-field resolution and can no longer resolve the
aws-core-vscode/shared subpath from compiled packages/core/dist in the
web bundle, breaking the webBase build. Only the web jobs (package VSIX,
test Web) fail; all Node-based jobs pass.

Solution:
Revert webpack to ^5.95.0, restoring enhanced-resolve 5.17.1 to match
main. Dependabot #68/#69 are build-time SSRF in webpack's
HttpUriPlugin/buildHttp experimental feature, which this repo does not
use, so real-world risk is negligible. They are intentionally left open
and will be fixed thoroughly in a follow-up PR together with the
core exports / webpack resolve compatibility work.

* deps: resolve major-version Dependabot alerts (category 2) (#137)

Resolve the security alerts that require major-version bumps or
coordinated transitive upgrades, on top of the safe (category 1) fixes.
Brings total resolved to 152 of 160 open Dependabot alerts.

Direct bumps:
- markdown-it 13 -> ^14.2.0 (+ @types/markdown-it ^14.1.2) [core]
- esbuild-loader 2.20.0 -> 4.5.0 [core] (ESBuildMinifyPlugin -> EsbuildPlugin
  in webpack.base.config.js; pulls esbuild 0.25+)
- webpack-dev-server ^4.15.2 -> ^5.2.5 (devServer config uses only options
  still valid in v5)

Overrides / range updates (root):
- fast-xml-parser -> 5.7.0 (GHSA-gh4j has no 4.x backport; forces the
  AWS SDK's XML parser to 5.x - see risk note)
- markdown-it 14.2.0, linkify-it 5.0.1, jsonata 2.2.1
- js-yaml@4 -> 4.2.0 (scoped so js-yaml 3.x consumers are untouched)
- @smithy/config-resolver, @opentelemetry/core updated to patched lines

src.gen streaming clients:
- fast-xml-parser override 4.5.7 -> 5.7.0

Note: keeps webpack at ^5.95.0 (see PR #136) so the web build stays green;
webpack #68/#69 remain deferred and are addressed separately in this PR.

Risk to validate in CI: forcing fast-xml-parser 5.x onto the AWS SDK may
affect XML-based SDK responses (S3/EC2/CloudFormation).

* fix: resolve CodeQL code-scanning security alerts (#140)

* fix: resolve CodeQL code-scanning security alerts

Problem:
17 open CodeQL code-scanning alerts across source, tests, dev scripts,
and a workflow (ReDoS, incomplete sanitization, shell-command injection
from environment, and a missing workflow permissions block).

Solution:
- ReDoS (js/polynomial-redos): rewrite vulnerable regexes as linear
  equivalents - indent()/block-comment/base64url padding in
  textUtilities.ts; use-strict/require detection in importAdderUtil.ts;
  trailing '/' and '#' stripping in auth.ts and authUtil.ts (behavior
  verified against existing unit tests).
- Shell injection (js/shell-command-injection-from-environment): replace
  execSync(string) with execFileSync('git', [...args]) (no shell) in
  scripts/createRelease.ts and scripts/newChange.ts.
- Incomplete sanitization (js/incomplete-sanitization): replace all
  quotes, not just the first, in ssh.test.ts.
- URL substring checks (js/incomplete-url-substring-sanitization): use
  assert.match instead of includes() on URLs in
  referenceLogViewProvider.test.ts.
- Workflow permissions (actions/missing-workflow-permissions): add a
  least-privilege top-level 'contents: read' to release.yml (the publish
  job keeps its explicit 'contents: write').
- Certificate validation (js/disabling-certificate-validation): this is
  an explicit user opt-in mirroring VS Code's 'http.proxyStrictSSL';
  kept the behavior, upgraded the log to a warning, and documented it.

None of these overlap with the dependency PRs (#136-138).

* fix: match quoted use-strict directive after ReDoS hardening

The anchored /^\s*use\s+strict/ regex missed quoted directives like
'use strict'; (line starts with a quote), breaking
importAdderUtil 'first line after comments and use strict'. Allow an
optional leading quote: /^\s*['"]?use\s+strict/ (still anchored/linear).

* fix: strip all block comments in stripNewLinesAndComments

Add the global flag to the ReDoS-hardened block-comment regex so lines
with multiple block comments are fully stripped (and code between them is
preserved), matching the function's documented intent. Addresses review
feedback on #140; the g flag keeps the regex linear (no ReDoS).

* deps: fix webpack SSRF alerts (#68, #69) via resolver pin (#138)

Problem:
Bumping webpack to the patched ^5.104.1 (fixes GHSA build-time SSRF
alerts #68/#69) pulls enhanced-resolve 5.24.x, whose stricter exports
resolution breaks the web bundle (aws-core-vscode/shared no longer
resolves from packages/core/dist), failing package VSIX and test Web.

Solution:
Bump webpack to ^5.104.1 and override enhanced-resolve to 5.17.1 (the
version main uses and known to resolve core's exports). npm overrides
bypass webpack's declared enhanced-resolve range, so the SSRF fix lands
while the lenient, working resolver is retained. Brings total resolved
to 154 of 160 Dependabot alerts.

Remaining 6 alerts are unpatched upstream (aws-sdk v2, elliptic),
require major upstream package upgrades (@opentelemetry/core via
@aws/language-server-runtimes, @smithy/config-resolver via old @aws-sdk
clients), or are stale/false-positive (@protobufjs/utf8).

* deps: resolve newly-expanded Dependabot advisories (#143)

Resolve 10 Dependabot alerts that re-surfaced after their advisories
were expanded to new version lines (or newly published) since the prior
security PRs merged. All verified against the current advisory ranges.

- koa 2.16.2 -> 2.16.4 (#99, #246)
- @tootallnate/once -> 2.0.1 (#214)
- brace-expansion (1.x) -> 1.1.13 (#170, #20)
- yaml -> 1.10.3 (#157)
- immutable -> 4.3.8 (#131)
- minimatch (5.x) -> 5.1.8 (#106)
- diff (4.x -> 4.0.4, 5.x -> 5.2.2) (#55)
- glob (10.x) -> 10.5.0 (#36)

Uses version-scoped overrides (pkg@major) so other coexisting major
lines are untouched. Root lockfile only; verified idempotent.

Deferred: uuid #217/#219/#220 require a major 9->11 bump. uuid is a
direct dependency of the generated src.gen clients, so npm ignores an
override, and npm won't dedupe the hoisted 9.0.1 shared across older
@aws-sdk clients. That needs a dedicated effort (generated client +
@types/uuid updates) and is left for a follow-up.

* deps: fix critical websocket-driver advisory (#247) (#145)

Override websocket-driver to 0.7.5 (GHSA-xv26-6w52-cph6: message
corruption via abuse of protocol length headers, vulnerable < 0.7.5).
Transitive dev-only dependency via sockjs/faye-websocket. Single version
override; root lockfile only; verified idempotent.

* deps: bump adm-zip to 0.6.0 to patch high-severity advisory (#147)

Problem:
adm-zip ^0.5.10 (in packages/core) has an open high-severity Dependabot
advisory (alerts #249, #250). The root build scripts (scripts/lspArtifact.ts)
import adm-zip but only relied on it being hoisted from packages/core.

Solution:
- Bump adm-zip to ^0.6.0 in packages/core.
- Declare adm-zip ^0.6.0 (+ @types/adm-zip) in the root package.json, since
  the root build scripts import it directly — this keeps it resolvable at the
  root regardless of workspace hoisting (fixes "Cannot find module 'adm-zip'"
  during packaging).
- Regenerate the lockfile.

Other open alerts (uuid, @opentelemetry/core, @smithy/config-resolver —
multiple coexisting versions; aws-sdk, elliptic — no patch) are deferred for
scoped human review.

* test: bump @vscode/test-electron to ^3.1.0 to fix macOS insiders CI (#153)

* test: bump @vscode/test-electron to ^2.5.2 to fix macOS insiders CI

The 'test macOS (18.x, insiders)' job fails repo-wide (incl. on main)
with 'spawn .../Contents/MacOS/Electron ENOENT': the pinned
@vscode/test-electron 2.3.8 (2023) can't locate the executable in the
current VS Code Insiders macOS build. Bump to the latest Node-18-safe
line (2.5.2).

Note: the newest @vscode/test-electron (3.0.0) would be the most complete
fix but requires Node >=22 (CI runs Node 18) and restructures the
internal out/runTest import, so it is out of scope here. If 2.5.2 does
not fully resolve the insiders job, the follow-up is a coordinated
Node 22 + test-electron 3.0.0 upgrade.

* test: bump @vscode/test-electron to ^3.1.0 to fix macOS insiders CI

The 'test macOS (18.x, insiders)' job fails repo-wide with
'spawn .../Visual Studio Code - Insiders.app/Contents/MacOS/Electron ENOENT':
@vscode/test-electron 2.x resolves an executable path that current VS Code
Insiders macOS builds no longer use. Fixed in test-electron 3.x.

- Bump ^2.5.2 -> ^3.1.0 (matches upstream aws-toolkit-vscode)
- Import TestOptions/runTests from the package root; drop the internal
  '@vscode/test-electron/out/runTest' path

No CI Node bump needed: .npmrc sets engine-strict=false, so 3.x
(engines: node>=22) installs on the Node 18 runners, matching upstream.

* feat: distinct sign-in error when Q Developer is not accepting new customers

When RTS rejects an identity with AccessDeniedException and
reason=FEATURE_NOT_SUPPORTED, Amazon Q Developer is no longer accepting
that customer. Previously this surfaced as the generic "Failed to list Q
Developer profiles for regions: ..." error, which offers Retry and Sign
out actions -- both useless for a permanent, deliberate rejection, and
misleading because it reads as a transient outage.

RegionProfileManager now classifies this case and throws a ToolkitError
with code QDeveloperNotAcceptingNewCustomers carrying the real service
message. The login webview renders a dedicated state showing that
message with a single "Go back" action instead of Retry/Sign out.

Classification requires all three of: isAwsError (a real AWS service
error carrying code and time, not merely an object with a `reason`
field), name === 'AccessDeniedException', and reason exactly equal to
'FEATURE_NOT_SUPPORTED'. This deliberately avoids capturing the other
modeled AccessDeniedExceptionReason values --
UNAUTHORIZED_CUSTOMIZATION_RESOURCE_ACCESS,
UNAUTHORIZED_WORKSPACE_CONTEXT_FEATURE_ACCESS and TEMPORARILY_SUSPENDED
-- the last of which is transient and must keep its retry affordance.
Since the rejection is per-identity rather than per-region, the first
matching region wins and is preferred over the generic failure
regardless of which region's call settles first.

listRegionProfiles returns RegionProfile[] | string, so the specific
case is tagged for the frontend by prefixing the message with the
notAcceptingNewCustomersPrefix sentinel, which the Vue component strips
before display. That constant lives in types.ts rather than backend.ts
because backend.ts imports vscode and Auth; importing a runtime value
(not just a type) from it into a webview file bundles Node-only
dependencies into the webview bundle and blanks the view at load.

Adds signOutIfConnected() to CommonAuthWebview, backing the "Go back"
action. Unlike signout() it must never throw, because by the time the
user dismisses the error the connection may already have been cleared by
a connection-modified listener reacting to the auth failure; the action's
job is to return to a neutral login screen, not to assert a connection
existed.

Tests cover the positive case plus three negative cases that pin the
fallback to ListQDeveloperProfilesFailed: an unrelated
AccessDeniedException reason (TEMPORARILY_SUSPENDED), a
non-AccessDeniedException error coincidentally carrying
reason=FEATURE_NOT_SUPPORTED, and a generic transient failure.

* deps: fix protobufjs + newly-expanded advisories (#251-259) (#150)

* deps: fix protobufjs DoS advisory (#251)

Bump the protobufjs override 7.6.3 -> 7.6.5 (GHSA-j3f2-48v5-ccww:
DoS via infinite loop in .proto option parsing; vulnerable 7.5.0-7.6.4).
Transitive runtime dependency; single version in the tree; root lockfile
only; verified idempotent.

* deps: fix newly-expanded advisories (#252-258)

Bump existing overrides to the versions required by advisories that were
expanded/updated on 2026-07-21, re-flagging our pinned versions:
- brace-expansion (1.x) 1.1.13 -> 1.1.16 (#252)
- js-yaml (4.x) 4.2.0 -> 4.3.0 (#253)
- shell-quote 1.8.4 -> 1.9.0 (#254)
- immutable 4.3.8 -> 4.3.9 (#255, #256)
- fast-uri 3.1.2 -> 3.1.3 (#257)
- linkify-it 5.0.1 -> 5.0.2 (#258)

All verified resolved against the current advisory ranges; root lockfile
only; verified idempotent.

* deps: bump fast-uri to 3.1.4

* feat: detect Q Developer access blocks via the language server

Replaces the detection half of this change. The UI is unchanged.

The original approach classified the block from ListAvailableProfiles, which cannot
work for the population being blocked:

- RTS gates on the User-Agent of the shared language server
  (AWS-Language-Servers-AWS-CodeWhisperer). The extension's own SDK calls carry a
  different UA and are allowed unconditionally, so the extension is never told "no".
  Verified against prod: with a blocked Builder ID the extension's own
  ListFeatureEvaluations succeeds while the language server's identical call is denied.
- Profiles are an IdC concept. restoreProfileSelection() only runs behind
  isValidEnterpriseSsoInUse(), so a Builder ID user never reaches that path -- and IdC
  identities are exempt from the gate, so the one type that does reach it is never
  denied.
- For Builder ID, ListAvailableProfiles returns a different error ("AWS Builder ID is
  not supported for this operation", reason undefined) which is identical for healthy
  and blocked identities, so it cannot be used as a signal either.

The language server is therefore the only component that observes the rejection. It now
reports it over the existing Notification feature, and this change reacts to that:

- qDevAccessBlockedHandler listens for aws/window/showNotification, persists the
  service's message, and signs the user out.
- The blocked state is persisted so the message survives the sign-out that follows.
- showLoginView and refreshAuthState route a blocked identity to the existing blocked
  screen; listRegionProfiles short-circuits to the stored message rather than calling an
  API that cannot succeed.
- Go back clears the state and fires onActiveConnectionModified so the webview returns
  to sign-in. Firing is required, not incidental: reacting to the block already signed
  the user out, so signout() -- which would normally trigger the re-render -- is
  skipped, and without this the screen never changes.
- URLs in the message render as links. The message is the service's copy and contains
  the action the user must take, which is useless as inert text. Split into segments
  rather than v-html so a service response can never inject markup.

Requires a language server carrying the server-side reporting (aws/language-servers
 #2794, #2796, #2797). Older servers send nothing and this code stays dormant.

Tested end to end in VS Code against prod RTS with a blocked Builder ID: sign-in
succeeds, the block is reported seconds later, the user is signed out, the message
renders with a working kiro.dev link, and Go back returns to sign-in. Also verified a
healthy identity is unaffected.

* fix: identify the access-blocked notification by id, not by title

Review follow-up. The id check could never match and the title check was doing all the
work, which meant any future error notification titled "Amazon Q Developer" would have
signed a working user out.

The runtime does not forward the server's id verbatim: RouterByServerName replaces it
with base64 of {"serverName":...,"id":...} so followups can be routed back to the
originating server. So `params.id === 'qDevPluginAccessBlocked'` never matched, and the
title fallback was the only live path.

Decode the envelope and match on the inner id, falling back to the raw value so a server
sending a plain id still works. Title matching is removed entirely rather than kept as a
fallback: every server able to deliver a notification at all sends the id, so there is
nothing to fall back for, and the cost of a false positive here is signing out a user
who is not blocked.

Adds the tests this file should have had. One asserts an unrelated error notification
sharing the title is ignored, which is the regression that motivated the change; the
others cover the routed id, a plain id, a missing id, an empty message, idempotency on
repeated reports, and that the handler never throws when sign-out fails. 7 passing.

* fix: initialise load metadata when routing to the blocked screen

Routing a blocked identity to PENDING_PROFILE_SELECTION returned early without setting
loadMetadata, which the existing pendingProfileSelection branch does. When the webview
then reported readiness it broke:

    webviewId="aws.amazonq.AmazonCommonAuth": Error: Webview error
     -> Error: Webview backend command failed: "setUiReady()"
     -> TypeError: Cannot read properties of undefined (reading 'start')

setDidLoad dereferences loadMetadata!.start non-optionally, so entering that stage
without it throws inside the webview. The failure lands on exactly the users this feature
exists to help: they would see a broken login view instead of the explanation.

Both callers now go through enterProfileSelection() rather than duplicating the setup, so
a future third caller cannot miss it. The comment records why the metadata is required
rather than leaving it as unexplained bookkeeping.

Added a regression test asserting setUiReady does not throw after routing to the blocked
screen. Verified it bites: reintroducing the early return fails it (8 passing/1 failing
vs 9 passing).

* feat: redesign the access-blocked screen

Replaces the single-message screen with the layout Saurabh proposed, which explains why
access is blocked and what to do about it instead of only relaying the service's sentence.

- Heading and subheading stating that sign-ups have stopped, with the date
- Three cards: why this is happening (with a link to the announcement), what to use
  instead (Kiro), and that pre-cutoff Builder IDs can still sign in
- Primary action opens kiro.dev, secondary returns to sign-in, footer links to the
  announcement

The service message is no longer displayed. It is still stored, because its presence is
what marks the identity as blocked, but the screen now carries its own copy. Worth
knowing for review: that copy hardcodes two dates, so if the service changes its cutoff
the screen will not follow. The dates are Saurabh's, taken from the public announcement.

The container widens for this screen only, rather than changing the 260px cap the profile
picker relies on. Colours come from VS Code theme variables so the screen follows light
and dark themes; only the accent hues and the primary button gradient are fixed, since
those carry meaning rather than chrome. Icons are inline SVG rather than an icon font, to
avoid adding a webview dependency.

Removes the URL-splitting computed, which existed only to linkify the service message.

* fix: centre the access-blocked screen instead of overflowing its container

The container is capped at 260px and absolutely positioned for the profile picker. The
blocked screen is wider, and a wider child cannot centre inside it: with negative
available space the auto margins resolve to 0, so the content started at the container's
left edge and overflowed to the right while the Q icon above stayed centred in the 260px
box. The whole screen read as misaligned.

The container itself now widens for this state rather than the child overflowing it, so
the icon, heading, cards and buttons share one centre axis. Static positioning also drops
the fixed top offset, which only made sense for the short picker and left a large gap
above this taller screen.

* fix: repoint CODEOWNERS and workflow org guards to Amazon-Q-Developer

The repo moved from the aws org to Amazon-Q-Developer
(https://t.corp.amazon.com/P484890134).

- CODEOWNERS: the @aws/* teams do not exist in the new org, so every entry
  was an "Unknown owner" and code-owner review could not be satisfied. Collapse
  to @Amazon-Q-Developer/sync-team-dae-production-eng-team (the synced eng team),
  matching what was done for language-servers. Granular per-directory teams have
  no equivalent in the new org yet.
- node.js.yml / notification.yml: `github.repository == 'aws/amazon-q-vscode'`
  guards now evaluate false, silently skipping the Codecov upload and PR
  notification jobs. Repoint to Amazon-Q-Developer/amazon-q-vscode.

* build: merge release candidate version rc-20260819 (#174)

* Update third-party license attribution for release/rc-20260819

* Release 2.5.0

* Update version to snapshot version: 2.6.0-SNAPSHOT

---------

Co-authored-by: aws-toolkit-automation <>

* fix: unbreak the login webview shipped in 2.5.0 (#179)

Two defects compound into the black login view with "Error: Webview error" that customers
hit on IdC sign-in in 2.5.0. Diagnosed from the extension log of a live repro: the logged
failure is `Webview backend command failed: "setUiReady()" -> TypeError: Cannot read
properties of undefined (reading 'start')`.

1. The login Vue bundle ships wrapped in a CommonJS helper. esbuild-loader 4.5.0 (from the
   2.5.0 dependency remediation) infers `format: 'iife'` when the compile target is 'web'
   and the minifier target is not 'esnext', wrapping the whole bundle in a lazy CJS factory
   and rewriting top-level `this`, which also breaks `output.libraryTarget: 'this'`. Of the
   four Vue bundles in the shipped 2.5.0 VSIX, login/webview/vue/amazonq/index.js is the
   ONLY one wrapped -- feedback, codewhisperer and securityIssue shipped clean. Pinning the
   minimizer to target 'esnext' keeps esbuild as a pure minifier; the loader has already
   transpiled to es2021 and these bundles only run in the IDE's Chromium webview. This exact
   upgrade was reverted once before for the same breakage (91a54b0, "broke loading
   mynah-ui").

2. setDidLoad dereferences `loadMetadata!.start`. The webview's 10-second load timeout
   clears loadMetadata on the assumption the load failed, so a page that reports readiness
   late -- 44 seconds after activation in the captured log -- crashes the setUiReady
   command instead of recording a slow-but-successful load, and VS Code surfaces that as
   the webview error banner. Emit without a duration and return instead.

The rebuilt login bundle is verified free of the CJS wrapper.

---------

Co-authored-by: Laxman Reddy <141967714+laileni-aws@users.noreply.github.com>
Co-authored-by: Jacob Chung <chungjac@amazon.com>

* deps: resolve 123 Dependabot security alerts (safe, non-breaking) (#136)

* deps: resolve non-breaking Dependabot alerts (category 1)

Apply safe, in-major security fixes across all three lockfiles via npm
overrides pinned to GHSA-patched versions plus range-respecting updates
(no major-version bumps). Resolves 125 of 160 open Dependabot alerts.

Root package.json overrides: @xmldom/xmldom, cipher-base, fast-uri,
flatted, follow-redirects, form-data, koa, launch-editor, lodash, morgan,
node-forge, on-headers, pbkdf2, postcss, protobufjs, qs,
serialize-javascript, sha.js, shell-quote, tmp, undici, ws. Also bump
webpack devDependency to ^5.104.1 and range-update ajv, bn.js, glob,
tar-fs, picomatch, minimatch, brace-expansion, nanoid, playwright.

src.gen streaming clients: npm audit fix (lodash, minimatch,
@smithy/config-resolver) and override fast-xml-parser to 4.5.7.

Remaining alerts require major-version bumps or coordinated @aws-sdk
upgrades and are handled separately.

* deps: revert webpack bump to keep web build passing

Problem:
The webpack ^5.95.0 -> ^5.104.1 bump (added to fix SSRF alerts #68/#69)
pulls webpack 5.108.4 and enhanced-resolve 5.24.2. The newer resolver
applies stricter exports-field resolution and can no longer resolve the
aws-core-vscode/shared subpath from compiled packages/core/dist in the
web bundle, breaking the webBase build. Only the web jobs (package VSIX,
test Web) fail; all Node-based jobs pass.

Solution:
Revert webpack to ^5.95.0, restoring enhanced-resolve 5.17.1 to match
main. Dependabot #68/#69 are build-time SSRF in webpack's
HttpUriPlugin/buildHttp experimental feature, which this repo does not
use, so real-world risk is negligible. They are intentionally left open
and will be fixed thoroughly in a follow-up PR together with the
core exports / webpack resolve compatibility work.

* deps: resolve major-version Dependabot alerts (category 2) (#137)

Resolve the security alerts that require major-version bumps or
coordinated transitive upgrades, on top of the safe (category 1) fixes.
Brings total resolved to 152 of 160 open Dependabot alerts.

Direct bumps:
- markdown-it 13 -> ^14.2.0 (+ @types/markdown-it ^14.1.2) [core]
- esbuild-loader 2.20.0 -> 4.5.0 [core] (ESBuildMinifyPlugin -> EsbuildPlugin
  in webpack.base.config.js; pulls esbuild 0.25+)
- webpack-dev-server ^4.15.2 -> ^5.2.5 (devServer config uses only options
  still valid in v5)

Overrides / range updates (root):
- fast-xml-parser -> 5.7.0 (GHSA-gh4j has no 4.x backport; forces the
  AWS SDK's XML parser to 5.x - see risk note)
- markdown-it 14.2.0, linkify-it 5.0.1, jsonata 2.2.1
- js-yaml@4 -> 4.2.0 (scoped so js-yaml 3.x consumers are untouched)
- @smithy/config-resolver, @opentelemetry/core updated to patched lines

src.gen streaming clients:
- fast-xml-parser override 4.5.7 -> 5.7.0

Note: keeps webpack at ^5.95.0 (see PR #136) so the web build stays green;
webpack #68/#69 remain deferred and are addressed separately in this PR.

Risk to validate in CI: forcing fast-xml-parser 5.x onto the AWS SDK may
affect XML-based SDK responses (S3/EC2/CloudFormation).

* fix: resolve CodeQL code-scanning security alerts (#140)

* fix: resolve CodeQL code-scanning security alerts

Problem:
17 open CodeQL code-scanning alerts across source, tests, dev scripts,
and a workflow (ReDoS, incomplete sanitization, shell-command injection
from environment, and a missing workflow permissions block).

Solution:
- ReDoS (js/polynomial-redos): rewrite vulnerable regexes as linear
  equivalents - indent()/block-comment/base64url padding in
  textUtilities.ts; use-strict/require detection in importAdderUtil.ts;
  trailing '/' and '#' stripping in auth.ts and authUtil.ts (behavior
  verified against existing unit tests).
- Shell injection (js/shell-command-injection-from-environment): replace
  execSync(string) with execFileSync('git', [...args]) (no shell) in
  scripts/createRelease.ts and scripts/newChange.ts.
- Incomplete sanitization (js/incomplete-sanitization): replace all
  quotes, not just the first, in ssh.test.ts.
- URL substring checks (js/incomplete-url-substring-sanitization): use
  assert.match instead of includes() on URLs in
  referenceLogViewProvider.test.ts.
- Workflow permissions (actions/missing-workflow-permissions): add a
  least-privilege top-level 'contents: read' to release.yml (the publish
  job keeps its explicit 'contents: write').
- Certificate validation (js/disabling-certificate-validation): this is
  an explicit user opt-in mirroring VS Code's 'http.proxyStrictSSL';
  kept the behavior, upgraded the log to a warning, and documented it.

None of these overlap with the dependency PRs (#136-138).

* fix: match quoted use-strict directive after ReDoS hardening

The anchored /^\s*use\s+strict/ regex missed quoted directives like
'use strict'; (line starts with a quote), breaking
importAdderUtil 'first line after comments and use strict'. Allow an
optional leading quote: /^\s*['"]?use\s+strict/ (still anchored/linear).

* fix: strip all block comments in stripNewLinesAndComments

Add the global flag to the ReDoS-hardened block-comment regex so lines
with multiple block comments are fully stripped (and code between them is
preserved), matching the function's documented intent. Addresses review
feedback on #140; the g flag keeps the regex linear (no ReDoS).

* deps: fix webpack SSRF alerts (#68, #69) via resolver pin (#138)

Problem:
Bumping webpack to the patched ^5.104.1 (fixes GHSA build-time SSRF
alerts #68/#69) pulls enhanced-resolve 5.24.x, whose stricter exports
resolution breaks the web bundle (aws-core-vscode/shared no longer
resolves from packages/core/dist), failing package VSIX and test Web.

Solution:
Bump webpack to ^5.104.1 and override enhanced-resolve to 5.17.1 (the
version main uses and known to resolve core's exports). npm overrides
bypass webpack's declared enhanced-resolve range, so the SSRF fix lands
while the lenient, working resolver is retained. Brings total resolved
to 154 of 160 Dependabot alerts.

Remaining 6 alerts are unpatched upstream (aws-sdk v2, elliptic),
require major upstream package upgrades (@opentelemetry/core via
@aws/language-server-runtimes, @smithy/config-resolver via old @aws-sdk
clients), or are stale/false-positive (@protobufjs/utf8).

* deps: resolve newly-expanded Dependabot advisories (#143)

Resolve 10 Dependabot alerts that re-surfaced after their advisories
were expanded to new version lines (or newly published) since the prior
security PRs merged. All verified against the current advisory ranges.

- koa 2.16.2 -> 2.16.4 (#99, #246)
- @tootallnate/once -> 2.0.1 (#214)
- brace-expansion (1.x) -> 1.1.13 (#170, #20)
- yaml -> 1.10.3 (#157)
- immutable -> 4.3.8 (#131)
- minimatch (5.x) -> 5.1.8 (#106)
- diff (4.x -> 4.0.4, 5.x -> 5.2.2) (#55)
- glob (10.x) -> 10.5.0 (#36)

Uses version-scoped overrides (pkg@major) so other coexisting major
lines are untouched. Root lockfile only; verified idempotent.

Deferred: uuid #217/#219/#220 require a major 9->11 bump. uuid is a
direct dependency of the generated src.gen clients, so npm ignores an
override, and npm won't dedupe the hoisted 9.0.1 shared across older
@aws-sdk clients. That needs a dedicated effort (generated client +
@types/uuid updates) and is left for a follow-up.

* deps: fix critical websocket-driver advisory (#247) (#145)

Override websocket-driver to 0.7.5 (GHSA-xv26-6w52-cph6: message
corruption via abuse of protocol length headers, vulnerable < 0.7.5).
Transitive dev-only dependency via sockjs/faye-websocket. Single version
override; root lockfile only; verified idempotent.

* deps: bump adm-zip to 0.6.0 to patch high-severity advisory (#147)

Problem:
adm-zip ^0.5.10 (in packages/core) has an open high-severity Dependabot
advisory (alerts #249, #250). The root build scripts (scripts/lspArtifact.ts)
import adm-zip but only relied on it being hoisted from packages/core.

Solution:
- Bump adm-zip to ^0.6.0 in packages/core.
- Declare adm-zip ^0.6.0 (+ @types/adm-zip) in the root package.json, since
  the root build scripts import it directly — this keeps it resolvable at the
  root regardless of workspace hoisting (fixes "Cannot find module 'adm-zip'"
  during packaging).
- Regenerate the lockfile.

Other open alerts (uuid, @opentelemetry/core, @smithy/config-resolver —
multiple coexisting versions; aws-sdk, elliptic — no patch) are deferred for
scoped human review.

* test: bump @vscode/test-electron to ^3.1.0 to fix macOS insiders CI (#153)

* test: bump @vscode/test-electron to ^2.5.2 to fix macOS insiders CI

The 'test macOS (18.x, insiders)' job fails repo-wide (incl. on main)
with 'spawn .../Contents/MacOS/Electron ENOENT': the pinned
@vscode/test-electron 2.3.8 (2023) can't locate the executable in the
current VS Code Insiders macOS build. Bump to the latest Node-18-safe
line (2.5.2).

Note: the newest @vscode/test-electron (3.0.0) would be the most complete
fix but requires Node >=22 (CI runs Node 18) and restructures the
internal out/runTest import, so it is out of scope here. If 2.5.2 does
not fully resolve the insiders job, the follow-up is a coordinated
Node 22 + test-electron 3.0.0 upgrade.

* test: bump @vscode/test-electron to ^3.1.0 to fix macOS insiders CI

The 'test macOS (18.x, insiders)' job fails repo-wide with
'spawn .../Visual Studio Code - Insiders.app/Contents/MacOS/Electron ENOENT':
@vscode/test-electron 2.x resolves an executable path that current VS Code
Insiders macOS builds no longer use. Fixed in test-electron 3.x.

- Bump ^2.5.2 -> ^3.1.0 (matches upstream aws-toolkit-vscode)
- Import TestOptions/runTests from the package root; drop the internal
  '@vscode/test-electron/out/runTest' path

No CI Node bump needed: .npmrc sets engine-strict=false, so 3.x
(engines: node>=22) installs on the Node 18 runners, matching upstream.

* feat: distinct sign-in error when Q Developer is not accepting new customers

When RTS rejects an identity with AccessDeniedException and
reason=FEATURE_NOT_SUPPORTED, Amazon Q Developer is no longer accepting
that customer. Previously this surfaced as the generic "Failed to list Q
Developer profiles for regions: ..." error, which offers Retry and Sign
out actions -- both useless for a permanent, deliberate rejection, and
misleading because it reads as a transient outage.

RegionProfileManager now classifies this case and throws a ToolkitError
with code QDeveloperNotAcceptingNewCustomers carrying the real service
message. The login webview renders a dedicated state showing that
message with a single "Go back" action instead of Retry/Sign out.

Classification requires all three of: isAwsError (a real AWS service
error carrying code and time, not merely an object with a `reason`
field), name === 'AccessDeniedException', and reason exactly equal to
'FEATURE_NOT_SUPPORTED'. This deliberately avoids capturing the other
modeled AccessDeniedExceptionReason values --
UNAUTHORIZED_CUSTOMIZATION_RESOURCE_ACCESS,
UNAUTHORIZED_WORKSPACE_CONTEXT_FEATURE_ACCESS and TEMPORARILY_SUSPENDED
-- the last of which is transient and must keep its retry affordance.
Since the rejection is per-identity rather than per-region, the first
matching region wins and is preferred over the generic failure
regardless of which region's call settles first.

listRegionProfiles returns RegionProfile[] | string, so the specific
case is tagged for the frontend by prefixing the message with the
notAcceptingNewCustomersPrefix sentinel, which the Vue component strips
before display. That constant lives in types.ts rather than backend.ts
because backend.ts imports vscode and Auth; importing a runtime value
(not just a type) from it into a webview file bundles Node-only
dependencies into the webview bundle and blanks the view at load.

Adds signOutIfConnected() to CommonAuthWebview, backing the "Go back"
action. Unlike signout() it must never throw, because by the time the
user dismisses the error the connection may already have been cleared by
a connection-modified listener reacting to the auth failure; the action's
job is to return to a neutral login screen, not to assert a connection
existed.

Tests cover the positive case plus three negative cases that pin the
fallback to ListQDeveloperProfilesFailed: an unrelated
AccessDeniedException reason (TEMPORARILY_SUSPENDED), a
non-AccessDeniedException error coincidentally carrying
reason=FEATURE_NOT_SUPPORTED, and a generic transient failure.

* deps: fix protobufjs + newly-expanded advisories (#251-259) (#150)

* deps: fix protobufjs DoS advisory (#251)

Bump the protobufjs override 7.6.3 -> 7.6.5 (GHSA-j3f2-48v5-ccww:
DoS via infinite loop in .proto option parsing; vulnerable 7.5.0-7.6.4).
Transitive runtime dependency; single version in the tree; root lockfile
only; verified idempotent.

* deps: fix newly-expanded advisories (#252-258)

Bump existing overrides to the versions required by advisories that were
expanded/updated on 2026-07-21, re-flagging our pinned versions:
- brace-expansion (1.x) 1.1.13 -> 1.1.16 (#252)
- js-yaml (4.x) 4.2.0 -> 4.3.0 (#253)
- shell-quote 1.8.4 -> 1.9.0 (#254)
- immutable 4.3.8 -> 4.3.9 (#255, #256)
- fast-uri 3.1.2 -> 3.1.3 (#257)
- linkify-it 5.0.1 -> 5.0.2 (#258)

All verified resolved against the current advisory ranges; root lockfile
only; verified idempotent.

* deps: bump fast-uri to 3.1.4

* feat: detect Q Developer access blocks via the language server

Replaces the detection half of this change. The UI is unchanged.

The original approach classified the block from ListAvailableProfiles, which cannot
work for the population being blocked:

- RTS gates on the User-Agent of the shared language server
  (AWS-Language-Servers-AWS-CodeWhisperer). The extension's own SDK calls carry a
  different UA and are allowed unconditionally, so the extension is never told "no".
  Verified against prod: with a blocked Builder ID the extension's own
  ListFeatureEvaluations succeeds while the language server's identical call is denied.
- Profiles are an IdC concept. restoreProfileSelection() only runs behind
  isValidEnterpriseSsoInUse(), so a Builder ID user never reaches that path -- and IdC
  identities are exempt from the gate, so the one type that does reach it is never
  denied.
- For Builder ID, ListAvailableProfiles returns a different error ("AWS Builder ID is
  not supported for this operation", reason undefined) which is identical for healthy
  and blocked identities, so it cannot be used as a signal either.

The language server is therefore the only component that observes the rejection. It now
reports it over the existing Notification feature, and this change reacts to that:

- qDevAccessBlockedHandler listens for aws/window/showNotification, persists the
  service's message, and signs the user out.
- The blocked state is persisted so the message survives the sign-out that follows.
- showLoginView and refreshAuthState route a blocked identity to the existing blocked
  screen; listRegionProfiles short-circuits to the stored message rather than calling an
  API that cannot succeed.
- Go back clears the state and fires onActiveConnectionModified so the webview returns
  to sign-in. Firing is required, not incidental: reacting to the block already signed
  the user out, so signout() -- which would normally trigger the re-render -- is
  skipped, and without this the screen never changes.
- URLs in the message render as links. The message is the service's copy and contains
  the action the user must take, which is useless as inert text. Split into segments
  rather than v-html so a service response can never inject markup.

Requires a language server carrying the server-side reporting (aws/language-servers
 #2794, #2796, #2797). Older servers send nothing and this code stays dormant.

Tested end to end in VS Code against prod RTS with a blocked Builder ID: sign-in
succeeds, the block is reported seconds later, the user is signed out, the message
renders with a working kiro.dev link, and Go back returns to sign-in. Also verified a
healthy identity is unaffected.

* fix: identify the access-blocked notification by id, not by title

Review follow-up. The id check could never match and the title check was doing all the
work, which meant any future error notification titled "Amazon Q Developer" would have
signed a working user out.

The runtime does not forward the server's id verbatim: RouterByServerName replaces it
with base64 of {"serverName":...,"id":...} so followups can be routed back to the
originating server. So `params.id === 'qDevPluginAccessBlocked'` never matched, and the
title fallback was the only live path.

Decode the envelope and match on the inner id, falling back to the raw value so a server
sending a plain id still works. Title matching is removed entirely rather than kept as a
fallback: every server able to deliver a notification at all sends the id, so there is
nothing to fall back for, and the cost of a false positive here is signing out a user
who is not blocked.

Adds the tests this file should have had. One asserts an unrelated error notification
sharing the title is ignored, which is the regression that motivated the change; the
others cover the routed id, a plain id, a missing id, an empty message, idempotency on
repeated reports, and that the handler never throws when sign-out fails. 7 passing.

* fix: initialise load metadata when routing to the blocked screen

Routing a blocked identity to PENDING_PROFILE_SELECTION returned early without setting
loadMetadata, which the existing pendingProfileSelection branch does. When the webview
then reported readiness it broke:

    webviewId="aws.amazonq.AmazonCommonAuth": Error: Webview error
     -> Error: Webview backend command failed: "setUiReady()"
     -> TypeError: Cannot read properties of undefined (reading 'start')

setDidLoad dereferences loadMetadata!.start non-optionally, so entering that stage
without it throws inside the webview. The failure lands on exactly the users this feature
exists to help: they would see a broken login view instead of the explanation.

Both callers now go through enterProfileSelection() rather than duplicating the setup, so
a future third caller cannot miss it. The comment records why the metadata is required
rather than leaving it as unexplained bookkeeping.

Added a regression test asserting setUiReady does not throw after routing to the blocked
screen. Verified it bites: reintroducing the early return fails it (8 passing/1 failing
vs 9 passing).

* feat: redesign the access-blocked screen

Replaces the single-message screen with the layout Saurabh proposed, which explains why
access is blocked and what to do about it instead of only relaying the service's sentence.

- Heading and subheading stating that sign-ups have stopped, with the date
- Three cards: why this is happening (with a link to the announcement), what to use
  instead (Kiro), and that pre-cutoff Builder IDs can still sign in
- Primary action opens kiro.dev, secondary returns to sign-in, footer links to the
  announcement

The service message is no longer displayed. It is still stored, because its presence is
what marks the identity as blocked, but the screen now carries its own copy. Worth
knowing for review: that copy hardcodes two dates, so if the service changes its cutoff
the screen will not follow. The dates are Saurabh's, taken from the public announcement.

The container widens for this screen only, rather than changing the 260px cap the profile
picker relies on. Colours come from VS Code theme variables so the screen follows light
and dark themes; only the accent hues and the primary button gradient are fixed, since
those carry meaning rather than chrome. Icons are inline SVG rather than an icon font, to
avoid adding a webview dependency.

Removes the URL-splitting computed, which existed only to linkify the service message.

* fix: centre the access-blocked screen instead of overflowing its container

The container is capped at 260px and absolutely positioned for the profile picker. The
blocked screen is wider, and a wider child cannot centre inside it: with negative
available space the auto margins resolve to 0, so the content started at the container's
left edge and overflowed to the right while the Q icon above stayed centred in the 260px
box. The whole screen read as misaligned.

The container itself now widens for this state rather than the child overflowing it, so
the icon, heading, cards and buttons share one centre axis. Static positioning also drops
the fixed top offset, which only made sense for the short picker and left a large gap
above this taller screen.

* fix: repoint CODEOWNERS and workflow org guards to Amazon-Q-Developer

The repo moved from the aws org to Amazon-Q-Developer
(https://t.corp.amazon.com/P484890134).

- CODEOWNERS: the @aws/* teams do not exist in the new org, so every entry
  was an "Unknown owner" and code-owner review could not be satisfied. Collapse
  to @Amazon-Q-Developer/sync-team-dae-production-eng-team (the synced eng team),
  matching what was done for language-servers. Granular per-directory teams have
  no equivalent in the new org yet.
- node.js.yml / notification.yml: `github.repository == 'aws/amazon-q-vscode'`
  guards now evaluate false, silently skipping the Codecov upload and PR
  notification jobs. Repoint to Amazon-Q-Developer/amazon-q-vscode.

* build: merge release candidate version rc-20260819 (#174)

* Update third-party license attribution for release/rc-20260819

* Release 2.5.0

* Update version to snapshot version: 2.6.0-SNAPSHOT

---------

Co-authored-by: aws-toolkit-automation <>

* fix: unbreak the login webview shipped in 2.5.0 (#179)

Two defects compound into the black login view with "Error: Webview error" that customers
hit on IdC sign-in in 2.5.0. Diagnosed from the extension log of a live repro: the logged
failure is `Webview backend command failed: "setUiReady()" -> TypeError: Cannot read
properties of undefined (reading 'start')`.

1. The login Vue bundle ships wrapped in a CommonJS helper. esbuild-loader 4.5.0 (from the
   2.5.0 dependency remediation) infers `format: 'iife'` when the compile target is 'web'
   and the minifier target is not 'esnext', wrapping the whole bundle in a lazy CJS factory
   and rewriting top-level `this`, which also breaks `output.libraryTarget: 'this'`. Of the
   four Vue bundles in the shipped 2.5.0 VSIX, login/webview/vue/amazonq/index.js is the
   ONLY one wrapped -- feedback, codewhisperer and securityIssue shipped clean. Pinning the
   minimizer to target 'esnext' keeps esbuild as a pure minifier; the loader has already
   transpiled to es2021 and these bundles only run in the IDE's Chromium webview. This exact
   upgrade was reverted once before for the same breakage (91a54b0, "broke loading
   mynah-ui").

2. setDidLoad dereferences `loadMetadata!.start`. The webview's 10-second load timeout
   clears loadMetadata on the assumption the load failed, so a page that reports readiness
   late -- 44 seconds after activation in the captured log -- crashes the setUiReady
   command instead of recording a slow-but-successful load, and VS Code surfaces that as
   the webview error banner. Emit without a duration and return instead.

The rebuilt login bundle is verified free of the CJS wrapper.

---------

Co-authored-by: Laxman Reddy <141967714+laileni-aws@users.noreply.github.com>
Co-authored-by: Jacob Chung <chungjac@amazon.com>